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(54) Method and apparatus for editing a diary page in HTML format 



(57) A method and apparatus to create a "diary" 
containing multimedia references tovtfeb sites that a us- 
er has visited. These references (also called "content 
objects" or "objects") can be addresses of, for example, 
text, bookmarks, images, programs, movies, etc. Many 
content objects are provided via the Web sites of "con- 
tent providers," with the specific intent of making the 
content objects available to a user to place in his diary. 
The name "diary" arises because the invention prefera- 
bly allows the user to save these references in associ- 
ation with dates and/or times. The pages of a user's di- 



ary may be navigated like a book, moving forward and 
backward through the pages or jumping to a particular 
page. In addition to storing references to Web informa- 
tion, the user can also jot down reminders, enter ap- 
pointments, and birthdays, etc. for dates. A user is al- 
lowed to choose a visual "theme" for the pages of his 
diary. This theme can be changed at any time by the 
user and reflects how the user wants to present himself 
and his diary to the world. The user can set various lev- 
els of privacy for different portions of his diary. Entries 
on a diary page can be moved or copied within a diary 
page or moved or copied to different diary pages. 
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Description 

BACKGROUND OF THE INVEtSTTION 

[0001] The present invention relates generally to 
computer networks and, specifically, to a method and 
apparatus for implementing a "diary" of Web pages or 
the like on a computer network. 

[0002] In recent times, the internet has gained univer- 
sal acceptance. A global network connecting millions of 
computers, the Internet is the current "ultimate" in infor- 
mation and communication technology. Still, it has quite 
a few drawbacks. Some drawbacks, such as its speed 
(or lack thereof) are readily apparent to the casual user. 
Other problems are not as obvious. 
[0003] A first problem is the tacelessness of the Inter- 
net. In real life, we (consciously or unconsciously) 
■judge a book by its cover," i.e., we form an opinion 
about other people based on how they present them- 
selves, through their style of clothing, the car they drive, 
their hobbies and interests, and the people they admire 
or detest. Non-technical users of the Internet find it dif- 
ficult to present themselves, other than what they say in 
newsgroups, etc. Technically -minded users have some 
ability to present themselves through their Websites. 
However, setting up and maintaining a Website requires 
more knowledge and effort than many users possess. 
To design a good personal Website a user needs to 
know about such areas as computer science, human- 
computer interface design, graphic design, fine art, and 
writing. It is obvious from many examples available on 
the Web today that not all users have all of these skills 
in equal proportions. As such, the Internet is essentially 
a faceless medium. 

[0004] A second problem with the Internet is its vola- 
tility. While browsing the World Wide Web, users en- 
counter huge amounts of information. In the real world, 
when we visit a place, we take home a tangible memory 
of the place, such as photographs or souvenirs. Web 
users do not have this option. Current mechanisms for 
saving references to Web pages (e.g., bookmarks and 
favorite lists) have the large drawback of being text-ori- 
ented and, therefore, provide no visual (or other) clue 
as to why the user originally thought the Information was 
interesting enough to bookmark. The only merrwrles a 
Web user has of the sites he has visited are some rather 
inexpressive bookmarks that say something like "Wel- 
come to the homepage of SomeCompany" or "http:// 
www.somecompany.com/". Such bookmarks give no 
sensory clue as to why the user bookmarked the' page 
in the first place. Thus, a user's travels on the Web are 
rather volatile, since he has nothing tangible by which 
to remember where he has gone. What is needed is a 
way for users to keep track of locations that they have 
visited in a more visual and memorable way. 



SUMMARY OF THE INVENTION 

[0005] Particular and preferred aspects of the inven- 
tion are set out in the accompanying independent and 
5 dependent claims. Features of the dependent claims 
nnay be combined with those of the independent claims 
as appropriate and In connbi nations other than those ex- 
plicitly set out in the claims. 

[0006] The present invention allows a user to create 

10 a "diary" containing multimedia references to web sites 
that the user has visited. These references (also called 
"content objects" or "objects") can be addresses or ^ 
URLs of. for example, text, bookmarks, images, pro- 
grams, movies, etc. Many content objects are provided 

15 via the Web sites of "content providers," with the specific 
intent of making the content objects available to a user 
to place in his diary. Other content objects can be copied 
from the diaries of other users. Still other content objects 
are entered by the diary owner himself. 

20 [0007] The term "diary" arises because the invention 
preferably allows the diary owner to save these refer- 
ences in association with dates and/or times. Thus, at 
least part of the user's diary will likely organize informa- 
tion about web pages (and other types of information 

25 Specified by the diary owner) by dates. Other parts of a 
diary organize data according to type of data, having a 
diary page for such types of Information as "recipes," 
telephone numbers, favorite Websites, etc. The pages 
of a user's diary may be navigated like a book, moving 

30 forward and backward through the pages or jumping to 
a particular page. In addition to storing references to 
Web information, the diary owner can also jot down re- 
minders, enter appointments, and birthdays, etc. for 
dates. 

35 [0008] A diary owner Is allowed to choose a visual 
"theme" for the pages of his diary. This theme can be 
changed at any time by the diary owner and reflects how 
the diary owner wants to present himself and his diary 
to the world. A theme Is reflected in a "cover" of a user's 

40 diary and in the design and general layout of the pages 
in the user's diary. These themes and covers are gen- 
erally designed by professional graphics artists and pro- 
vide an opportunity for revenue via the placement on the 
cover of ads or graphics associated with a particular 

45 company or product. In fact, the ultimate "ads" cover 
may be created when a single company creates a cover 
as an ad for itself. The company pays a licensing fee for 
the ability to provide a cover and for the right to be men- 
tioned in a list of possible covers. 

so [0009] The diary owner can set various levels of pri- 
vacy for different portions of his diary. Thus, only certain 
portions of the diary (for example, a daily entry or a re- 
minder list) can be viewed only be the diary owner, while 
other portions of the diary can be viewed by anyone with 

55 a Web browser. Thus, a diary owner may organize all or 
part of his diary to present an image of himself to the 
world. 

[0010] The present invention allows "content provid- 
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ers" to place content ("souvenirs") on their Web page. 
Diary owners can then download a reference to the con- 
tent Into their personal diaries. When a user views the 
Web page of a content provider, he can choose to add 
one or more pieces of content offered on the Web page 
to his diary. A downloadable content object on a content 
provider web site has an associated executable pro- 
gram, such as a JavaScript, to aid in placing a reference 
to the content into the diary as discussed below in con- 
nection with Figs. 5(a) and 5(b). 
[0011] The diary owner can edit existing diary content 
and layout by entering an edit mode, which allows the 
owner to move and copy pieces of the content of a diary 
page, either within the page or to another page. A diary 
applet regenerates the page to reflect the editing chang- 
es and passes it to the browser for display. 
[0012] The Java execution environment implements 
certain security restrictions for Java applets. All Java 
parts of the diary embodiment are implemented as ap- 
plets, so these security reslriclions apply. Specifically, a 
Java applet that was loaded from a server machine, onto 
a user machine to communicate with a different ma- 
chine, such as content provider machine, can be prob- 
lematic. Similarly, most Java execution environments do 
not allow Java applets to read, write, create, delete, or 
otherwise modify or examine the local file system. The 
first limitation raises problems when a diary owner wants 
to use content provided by a third party. Use of such 
content is described in detail in copending U.S. Patent 
Application No. 09/144.71 7, entitled "Systenn and Meth- 
od for Generating, Transferring, and Using an Annotat- 
ed Universal Address" by van der Meer and a corre- 
sponding European application having the same title 
filed contemporaneously herewith, a copy of which is 
supplied herewith for placement on the public file of this 
application. 

[001 3] The described embodiments of the present in- 
vention provide an Implementation of the transfer func- 
tion to save data from a third party provider between the 
diary applet (in the owner system) and the diary server 
(which stores diary data) that overcomes this restriction. 
While the three machines are typically separate, this 
method works even when one or more of the machines 
are the same. This transfer mechanism is not limited to 
diary applications and is usable in various other circum- 
stances, such as whenever an executable program 
loaded from a first machine to a second machine needs 
to communicate with a third machine. 
[0014] In accordance with the purpose of the inven- 
tion, as embodied and broadly described herein, the in- 
vention relates to a method of editing content displayed 
on a diary page described by a web descriptor language, 
comprising: receiving an indication from the user to en- 
ter an edit mode for the diary page; generating In re- 
sponse to the indication, by a executable diary program 
running within a browser, a second executable as a part 
of the descriptor language of the page, where the sec- 
ond executable informs the executable diary program 



whenever the user selects content to edit; displaying a 
user edit interface, by the executable diary program af- 
ter being informed by the second executable that the 
user has selected content to edit; and regenerating de- 

s scriptor language, by the executable diary program^ run- 
ning within the browser, for the diary page In accordance 
with edits made via the user edit interface. 
[0015] In further accordance with the purpose of the 
invention, as embodied and broadly described herein, 

10 the invention relates to an apparatus that allows a user 
to edit content displayed on a diary page described by 
a web descriptor language, comprising: a portion con- 
figured to receive an indication from a user to enter an 
edit mode for the diary page; a portion configured togen- 

is erate in response to the indication, by a executable diary 
program running within a browser, a second executable 
as a part of the descriptor language of the page, where 
the second executable informs the executable diary pro- 
gram whenever the user selects content to edit; a por- 

20 lion configured lo displaying a user edit interface, by the 
executable diary program after being Informed by the 
second executable that the user has selected content 
to edit; and a portion configured to regenerate descriptor 
language, by the executable diary program, running 

25 within the browser, for the diary page in accordance with 
edits made via the user edit interface. 
[0016] Advantages of the invention will be set forth in 
part in the description which follows and in part will be 
obvious from the description or may be learned by prac- 

30 tice of the invention The objects and advantages of the 
Invention will be realized and attained by means of the 
elements and combinations particularly pointed out in 
the appended claims and equivalents. 



[0017] The accompanying drawings, which are incor- 
porated in and constitute a part of this specification. Il- 
lustrate several embodiments of the invention and, to- 
40 gether with the description, serve to explain the princi- 
ples of the invention. 

[001 8] Fig. 1 (a) is a block diagram showing exemplary 
physical connections between elements of a system In 
accordance with an embodiment of the present Inven- 
ts tion. 

[0019] Fig. 1 (b) Is a block diagram of a computer net- 
work in accordance with an embodiment of the present 
Invention, showing how a user's diary is viewed or edit- 
ed. 

50 [0020] Fig. 1 (c) is a block diagram of a computer net- 
work in accordance with an embodiment of the present 
invention, showing how a content provider creates a di- 
ary cover. 

[0021] Fig. 2(a) Is a block diagram of a data process- 
es ing system acting as a diary owner system. 

[0022] Fig. 2(b) is a block diagram of a data process- 
ing system acting as a diary server 
[0023] Fig. 3 is a flow chart showing steps to view or 
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edit a diary. 

[0024] Fig 4(a) shows an exempt^ry web page being 
viewed with a browser, and also shows a diary navigator 
bar. 

[0025] Fig. 4(b) shows an exemplary Sections win- 5 
dow that allows the user to choose a non -dated diary 
section (or page) to view. 

[0026] Fig. 4(c) shows an exemplary Calendar Win- 
dow that allows a user to select a dated diary section 
(or page) to view. io 
[0027] Fig. 4(d) shows an exemplary Privacy window 
that allows an owner to set the privacy attributes of a 
diary section, page, or content object. 
[0028] Fig. 4(e) shows an exemplary Notes window 
that allows the diary owner to add notes to a link on a is 
diary page. 

[0029] Fig. 4(f) shows an exemplary Advanced win- 
dow that allows a diary owner to perform various ad- 
vanced editing functions on a diary page. 
[0030] Fig. 4(g) shows an exemplary Add Entry win- 20 
dow that allows a diary owner to add various types of 
content to a diary page. 

[0031] Fig. 4(h) shows an exemplary window allowing 
a diary owner to add content of type image to a diary 
page. 25 
[0032] Fig. 4(i) shows an exemplary window that al- 
lows the diary owner to manipulate existing content on 
a diary page. 

[0033] Fig. 4(j) shows an exemplary diary page as dis- 
played in edit mode. 30 
[0034] Fig. 4(k) shows an exemplary copy/move win- 
dow that allows a diary owner to copy or move content 
objects from and/or within their diary page. 
[0035] Fig. 4(1) is a flow chart showing how an edit is 
performed on content during edit mode. 35 
[0036] Fig. 4(m) shows an exemplary diary page after 
a content object has been moved, but while the page is 
still in edit mode. 

[0037] Fig. 4(n) shows an exemplary diary page after 
a content object has been moved, and after an exit from 40 
edit mode. 

[0038] Fig. 4(o) shows an exemplary diary page after 
a content object has been copied to another page and, 
and after an exist from edit mode. 

[0039] Fig. 5(a) shows an overview of a first em bod i- 45 
ment of a data transfer function involving three ma- 
chines. 

[0040] Fig. 5(b) shows an overview of a second em- 
bodiment of a data transfer function involving three ma- 
chines. ' 
[0041] Fig. 6(a) shows a Web page fetched from a 
content provider system allowing the diary owner to add 
some content on the page to his diary. 
[0042] Fig, 6(b) shows an example of a window gen- 
erated by an executable function during transfer of data 
between three machines, to prompt a diary owner for 
his name and diary server 

[0043] Fig. 7(a) shows an example of a window dis- 
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played during transfer of data between three machines. 
[0044] Fig. 7(b) shows an example of a window dis- 
played during transfer of data between three machines. 
[0045] Fig. 8 shows an exemplary architecture for an 
embodiment of the present invention. 
[0046] Fig. 9 lists exemplary files provided by cover 
providers in a preferred embodiment of the present in- 
vention. 

[0047] Fig. 10 lists exemplary files provided to gener- 
ate the contents of diary pages in a preferred embodi- 
ment of the present invention. 

[0048] Fig. 11 shows an exemplary format of an AUA- 
database of Fig. 10. 

[0049] Fig. 12 shows exemplary cover HTML-files in 
a preferred embodiment of the present invention. 
[0050] Fig. 13 shows a diagram of a relationship be- 
tween various kinds of covers and the layout of pages 
generated by a diary applet. 

DETAILED DESCRIPTION OF Ef^BODIIWENTS 

[0051] Reference will now be made in detail to several 
embodiments of the present invention, examples of 
which are illustrated in the accompanying drawings. 
V\flnerever practicable, the same reference numbers will 
be used throughout the drawings to refer to the same or 
like parts. 

A. General Discussion 

[0052] The present invention allows a diary owner to 
organize his information like a book. This information in- 
cludes links to web sites he has visited and to content 
he hias chosen to add to the diary. A diary includes one 
or more "sections." Each section contains one or more 
pages. The owner of the diary inserts "content objects" 
into the pages and sections of his diary. Some sections 
have a theme, such as "Recipes," 'Telephone Number, 
■ or 'Favorite Sites." All other sections correspond to a 
date. Optionally, content objects may be organized by 
time. The described embodiment of the present inven- 
tion handles time attached to content objects in a well- 
known and intuitive way. For example, it may sort these 
content objects by time and present them in the diary 
organization before content objects without time at- 
tached. 

[0053] A diary has a book design. The book design 
determines the graphics and layout of content within 
pages of a diary. A book design includes page designs, 
and how page designs are mapped to actual pages of 
the diary. A page design may be unique to a section or 
repeated within a section or across sections. For exam- 
ple, the same page design may be applied to all Monday 
pages. The page design defines the visual and audible 
appearance of the page. A page design provides slots 
for content entries or objects. The page design deter- 
mines the size and location of these slots within the 
page. 
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[0054] Diary owners insert content objects into pages. 
When a content object is inserted into a page, it is dis- 
played in one of the slots provided by the page design 
of the page. A content object can be any type of object, 
including text, bookmarks, innages. programs, movies, 
etc. The set of content objects inserted into the diary by 
the user is known as the "book content." 
[0055] Unlike a traditional book, the book design and 
book content of a diary are independent. Both of the 
book design and the book content may be changed at 
any point in time. The owner of a diary can switch book 
design at any time. The designer of a book design may 
change the book's design at any time. 
[0056] The diary software dynamically combines the 
diary's book design and book content to present a co- 
hesive view of the 'book.' Furthermore, a single book 
content may have many different vievws, each with a dif- 
ferent book design. 

[0057] The described embodiments of the present in- 
vention are empowered by features that only an elec- 
tronic book can offer. The electronic book can be 
stretched whenever required. The owner of the diary 
may add new sections to the book. The diary determines 
the number of pages in a section by the amount of con- 
tent placed by the diary owner into the section. When- 
ever the number of pages of a section is insufficient to 
contain the amount of content in the section, the diary 
adds a new page to the section automatically. Similarly, 
the diary automatically deletes unused pages in a sec- 
tion 

[0058] Like other electronic books, the diary can be 
accessed through an electronic network. The diary can 
be read in concurrently by multiple users in different lo- 
cations. Furthermore, different constituents of the diary 
may be stored or located in different locations within the 
network. For example, the book design, book content, 
parts of the book design, or content entries may be lo- 
cated in different locations within the network. 
[0059] In the described embodiment, the diary may 
enforce privacy-rules on any part or level of the book, i. 
e. book, section, page, individual content entry. Other 
embodiments may implement other levels of privacy 
rules and multiple implementations of this privacy con- 
cept are possible. In various implementations, privacy 
enforcement may be either advisory or mandatory. Dif- 
ferent authentication and verification schemes may be 
employed to identify the user attempting to access the 
book If a user does not have sufficient permission to 
view an object in a diary, the diary may not make the 
object visible to the user, i.e., the user does not even 
know that the object exists, or it may present the object 
using an alternate representation. 
[0060] The diary has electronic search and naviga- 
tional capability. The user of a diary may jump directly 
to any section/page of the book directly by electronic 
navigation through the book. The diary has dedicated 
search optbns to speed up access to content. For ex- 
ample, the user may have the option to jump to the most 



recent or nearest future section/page that contains at 
least one content entry. 

[0061] The diary provides means to manipulate the 
contents in the book. A diary owner can provide permis- 

5 sion to authorized users to insert content entries manu- 
ally or by any other means, copy, delete, or move con- 
tent entries. Content entries may be manipulated one at 
a time, or in larger groupings. For example, all the con- 
tent entries within a section may be manipulated as a 

10 group, the content entries within a range of sections may 
be manipulated as a group, or all the content entries in 
the book may be manipulated as a whole. 
[0062] Fig. 1 (a) shows a physical connection between 
three data processing systems: a user system 102, a 

15 diary server 104, a cover provider 105, and a content 
provider 106. It will be understood that, although only 
one of each kind of system is shown for clarity, there 
may be many user systems 102, many diary server sys- 
tems 104, many cover provider systems 105, and many 

20 content provider systems 1 06. A user normally has one 
diary on one diary server, but a user can also have mul- 
tiple diaries on one or on multiple diary servers. Each of 
the data processing systems communicates with the 
others via a network 1 40. Network 1 40 can be the Inter- 
ns net, a WAN, a LAN, a wireless network, a cellular tele- 
phone network, a radio frequency network, or any other 
appropriate network or connection. 
[0063] Fig. 1 (b) is a block diagram of a computer net- 
work in accordance with an embodiment of the present 

30 invention, showing how a diary is edited or viewed. Fig. 
1(b) includes user system 102. diary server 104. and 
one or more content providers 106. User system 102 
can be the system of the owner of the diary or a system 
of some other person who wishes to view the diary. User 

35 system 1 02 includes a browser 1 1 0 (which is shown ex- 
ecuting a diary applet downloaded from diary server 
104) and diary information 114 containing Information 
about the diary of this diary owner. One of the functions 
of diary applet 112 is to generate the HTML 111 for the 

40 Web pages of the user's diary (which preferably are dis- 
played by browser 11 0 in the browser window) on output 
device 222 (see Fig. 2(a)). 

[0064] Diary server 104 includes diary information 
122 (which includes diary information for a plurality of 

45 users' diaries), diary software 1 24, and an original copy 
of diary applet 112, residing with the HTML or other de- 
scription language 113 needed to display an initial Web 
page. Throughout this document, although the embod- 
iment is described in connection with HTML (Hypertext 

50 Markup Language), it will be understood that the inven- 
tion can be implemented using any appropriate descrip- 
tor language. Similarly, while the described embodiment 
uses a Java applet 11 2, any appropriate executable pro- 
gram can be used to implement the functionality of diary 

55 applet 112, including but not limited to JavaScript, Ac- 
tiveX controls. Visual BasiC; and plug-ins. In the de- 
scribed embodiment, a user begins viewing or editing a 
diary by viewing a Web page 1 1 3 available from the diary 
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server. This web page allows the user to indicate that 
he wishes to view or edit a specified diary. This indica- 
tion begins execution of diary applet 112, which sends 
a request 116 to diary server 104 for the contents ol the 
specified diary. When diary software 124 receives re- 
quest 116 from browser 110, it sends information 118 
appropriate for the specified diary to the user system. 
This infornnation 118 Includes diary information, an ex- 
ample of which is discussed below in connection with 
Figs. 9 and 1 0. 

[0065] Diary applet 112 reads diary information 114 
received from the sen/er and generates HTML 111 for 
one or more diary pages in accordance with diary infor- 
mation 114. Diary applet 112 instructs the browser 110 
to display the diary page(s) in the browser window. In 
the described embodiment, diary applet 112 communi- 
cates with the user both through the browser window 
and via a user interface popped up by the applet (see, 
e.g., Fig. 4(a)). All direct interaction (i.e., all interaction 
thai is not done via the browser window) o( the diary 
applet with the user is by windows that are popped up 
by diary applet 112. 

[0066] It will be understood that all or part of a per- 
son's diary can be viewed either by the owner of the di- 
ary or by other people, depending on howthe owner sets 
privacy values associated with the diary. In fact, a per- 
son's diary pages can, in general be viewed by any per- 
son having access to a browser. The browser can be a 
standard Web browser, such as Navigator, available 
from Netscape Corp. and Explorer, available frorri Mi- 
crosoft Corp. and does not need to be modified to allow 
a user to view an existing diary. 

[0067] Fig. 1 (c) is a block diagram of a computer net- 
work in accordance with an embodiment of the present 
invention, showing how a content provider creates a di- 
ary cover using a cover provider system 1 05. The cover 
provider can be, for example, an entity who has paid a 
fee to be allowed to create diary covers that diary own- 
ers can use in their diaries. It is anticipated that cover 
providers will add advertisements, product placements, 
or the like to their covers, but this is not required. A cover 
provider executes an enhanced version of diary applet 
112. 

[0068] Fig. 2(a) is a block diagram of a data process- 
ing system acting as a user system 102. Fig. 2(b) is a 
block diagram of a data processing system acting as a 
diary server 1 04. Data processing systems 1 02, 1 04 in- 
clude processors 202, 252 and storage areas (such as 
memories) 204, 254. Storage area 204 in user system 
102 includes a browser 210 and diary informatiori 212. 
Browser 210 can be any appropriate browser, including 
but not limited to Navigator and Explorer. Storage 254 
in diary server 1 04 includes diary information 1 22 for all 
users and diary software 124 for communicating with 
applet 1 1 2. 

[0069] Systems 1 02, 1 04 also include an input device 
220, 270 such as a mouse, a keyboard, a touch screen, 
or any other appropriate device. Systems 1 02. 1 04 also 
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include an output or display device such as a display 
screen. nr»onitor, or any other appropriate device. Cer- 
tain implementations of the invention include sound ca- 
pability. Both system 102. 104 connect to a network 
5 such as the Internet or any other appropriate network 
via a connection 230, 280. 

[0070] In certain embodiments, diary server 104 in- 
cludes a computer readable medium input device 274, 
which is capable of reading a computer readable medi- 
co um 276. A person of ordinary skill in the art will under- 
stand that the systems of Figs. 2(a) and 2(b) may also 
contain additional elements, such as input/output lines; 
additional input devices and additional display devices. 
The systems of Figs. 2(a) and 2(b) also may include ap- 

'5 plication programs, operating systems, data, etc., which 
are not shown in the figure for the sake of clarity. It also 
will be understood that the systems of Fig. 2(a) and 2(b) 
can also include numerous elements not shown, such 
as disk drives, keyboards, display devices, network con - 

20 neclions, additional memory, additional CPUs, addition- 
al processors, LANs, input/output lines, etc. 
[0071] In the following discussion, it will be under- 
stood that the steps of methods and flow charts dis- 
cussed below preferably are performed by one of proc- 

25 essors 202, 252 (or other appropriate processor or proc- 
essors) executing instructions stored in storage areas 
204, 254 (or other appropriate storage areas). Specifi- 
cally, the steps of the embodiment described herein are 
performed by diary applet 112 when it executes in 

30 browser 100 (and by other executable programs within 
the browser as described below) and by diary 
soft ware 124. It will also be understood that the invention 
is not limited to any particular implementation or pro- 
gramming technique and that the invention may be im- 

3S plemented using any appropriate techniques for imple- 
menting the functionality described herein. The inven- 
tion is not limited to any particular programming lan- 
guage, operating system, or network protocol. 
[0072] Some or all of the instructions and data struc- 

40 tures in storage areas 254 may be read into memory 
from computer- readable media 276. Execution of se- 
quences of instructions contained in the storage areas 
causes processors 202 or 252 to perform the process 
steps described herein. 

45 [0073] In alternative embodiments, hard -wired circuit- 
ry may be used in place of or in combination with soft- 
ware instructions to implement the invention. Thus, pre- 
ferred embodiments of the invention are not limited to 
any specific combination of hardware circuitry and soft- 

50 ware. The instructions performed by the processors can 
also be transmitted over a carrier wave in a computer 
network such as the internet, an intranet, a LAN, a WAN, 
and so on. 

55 B. Overview of Viewing and/or Editing a Diary 

[0074] Fig. 3 is a flow chart 300 showing steps to view 
or edit a diary. In general, steps of the left side of the 
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figures are performed by diary applet 112 executing in 
a browser of user system 102, while steps on the right 
side of the figure are performed by diary software 124 
executing in diary server system 104. In step 302. the 
user starts his browser 110 and views an initial diary web 
page (not shown) received by the browser in a manner 
known to persons of ordinary skill in the art. This diary 
web page allows new diary owners to register and to 
pick initial covers for their diaries (not shown), while al- 
lowing existing diary owners to decide to view and/or 
edit their diaries and allowing any person to view the 
non-private diaries of others. In step 304, the user indi- 
cates that he wishes to view or edit a diary, diary applet 
112 is obtained from system 104 and executed within 
browser 110 and the remainder of steps of Fig. 3 are 
performed. 

[0075] In step 304, diary applet 1 1 2 sends the request 
for diary informatbn to diary server system 104, where, 
in step 306, diary server system 1 04 sends diary data 
122 for the specified diary to applet 112. In a- preferred 
embodiment of the invention, this diary data is trans- 
ferred as a ASCII document, and not via the browser, 
although any appropriate format could be used. As will 
be understood by persons of ordinary skill in the art^ the 
applet and diary data could also already be stored in a 
cache of the system 102 and, therefore, it would not be 
necessary to transfer data from the server. This cache 
is not necessarily the browser cache. Diary applet 112 
receives diary data for the user and stores it in diary in- 
formation 114. In the described embodiment, diary in- 
formation stores three basic types of data: an AUA-da- 
tabase specifying the content of the diary page(s) that 
was gathered or created by the user; a cover (also called 
a cover or a "presentation context") for the diary, and 
configuration information for the user. An AUA is an 'An- 
notated Universal Address," as described in the afore- 
mentioned U.S. Patent Application No. 09/144,717, en- 
titled "System and Method for Generating, Transferring, 
and Using an Annotated Universal Address" by van der 
Meer and a corresponding European application having 
the same title filed contemporaneously herewith, a copy 
of which is supplied herewith for placement on the public 
file of this application. The AUA-database is user-spe- 
cific. The cover is shared by all users that have selected 
the same cover. The configuration information, such as 
privacy level, passwords, or the full name of the user, is 
user-specific. A fourth part (a backup AUA-database, 
not shown) can be created on the fly and is used to "go 
back" to previous diary content. 

[0076] In step 308, diary applet 1 1 2 generates one or 
more pages of the diary in HTML in accordance with the 
cover, content, and configuration information. The 
HTML is displayed as a diary page by browser 1 1 0. After 
generating a first page of the diary, diary applet 112 dis- 
plays a navigator bar or some other appropriate user 
interface, such as that shown in Fig. 4(a), and thereafter 
reacts to the actions of the user to view or change the 
diary, as described below. In step 310 diary applet 112 



sends changes (if any) for the user's diary to the diary 
server (periodically or at user's instruction). 

C. Navigation bv a user Within a Diary 

5 

[0077] The following section provides examples of the 
various functions of the diary navigation mechanism 
used in the described embodiment. It will be understood 
that the specific buttons and functionality described are 
10 provided by way of example and not of limitation. Other 
buttons and other functionality can be added and certain 
buttons and functionality can be omitted invention with- 
out departing from the spirit of the present invention. 

15 1 . The Navigation Bar 

[0078] In Fig. 4(a), exemplary diary page 400 Is being 
viewed with browser 110. and diary applet 112 has 
popped up a diary navigator bar window 402. In the Fig- 

20 ure, both diary page 400 and navigator bar 402 are dis- 
played on a display screen 404. As discussed above, 
diary page 400 was generated by diary applet 112 In 
accordance with diary information 11 4 for the diary page 
400, which was previously created by an owner of the 

2S diary. As can be seen, diary page 400 is an undated 
page entitled "Car Section" and Is dedicated to informa- 
tion added by the diary owner about cars. In the figure, 
the diary owner has previously added one Image of a 
car 410 to the diary page. Dated pages look similar, ex- 

30 cept that the date appears on the page (e.g. , at the top) 
and is associated with the page in the diary infomnation 
114. 

[0079] As shown In Fig. 4(a), navigator bar 402 In- 
cludes buttons 422, 424, 426, 428, 430, 432. 434, 436. 
35 438, 440. 442, 444, and 446. The first eight buttons are 
used to allow the user to move around within the pages 
and sections of a diary. Thus, button 422 represents a 
"Sections" function that allows the user to view undated 
sections of the diary. Buttons 424, 432 allow the user to 
40 display a first or last section that contains at least one 
content object. "First" and "last" are to be interpreted rel- 
ative to the section currently showing. Buttons 426 and 
430 allow the user to display the immediately previous 
or next section. "Previous" and "next" are to be Inter- 
ns preted relative to the section currently showing. For dat- 
ed sections, the previous section is the section that cor- 
responds to the date before the date currently showing. 
Next corresponds to the date after the dale currently 
showing. Buttons 428 allows the user to display a diary 
so page or section for a specific date. Each section, dated 
or not, can have multiple pages within the section. But- 
tons 434 and 436 allow the user to display next or pre- 
vious diary pages for a section (i.e., multiple diary pages 
may exist for each section). Button 438 allows a user to 
ss change the privacy level on which the diary Is operating, 
providing that the user is able to authenticate himself at 
the desired level. Buttons 440. 442. 444. and 446 are 
only available when the diary is operated at the "ovwier" 
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privacy level. Button 440 will pop-up a new window con- 
taining the advanced diary operations such as, e.g., 
nnoving or copying objects from one section to another. 
Button 442 allows a user to create a "text" object to be 
placed in the current sections. The final two buttons 444, 
446 provide access to a backup function and an edit 
property function. Button 446 is only present if the user 
who is running the diary applet is also registered as a 
cover builder. Button 446 allows the user to change the 
properties of the diary itsetf. 

[0080] Fig. 4(b) shows a Sections window that allows 
the user to move between undated sections in the diary. 
The user is presented with a list of existing sections. Di- 
ary applet 112 reads the user's selection and generates 
HTML for the selected section in accordance with diary 
information 114. In the window of Fig. 4(b) and others 
of the windows mentioned below, the user can click can- 
cel 405 or accept 406 to cancel or accept any changes 
he has made. 

[0081] Fig. 4(c) shows a calendar window that allows 
the user to move between dated sections in the diary. 
The user is presented with a calendar input that allows 
him to view a diary page for a given month, day, and 
year. Icon 407 is a shortcut. It indicates that the diary 
page for "today" should be displayed. Buttons 408 allow 
the user to increment or decrement a current year. Area 
409 allows the user to enter a year, which may be more 
efficient than incrementing or decrementing under cer- 
tain circumstances. Diary applet 112 reads the user's 
selection and generates HTML for the selected page or 
section in accordance with diary information 1 1 4. 

2. Privacy level of a diary page 

[0082] Button 438 allows any user to change the pri- 
vacy level on which the diary is operating, provided that 
the user is able to authenticate himself at the desired 
level. Authentication is preferably performed by requir- 
ing the user to enter a password required to change the 
privacy level to a certain level. In the described embod- 
iment, clicking or otherwise selecting this button dis- 
plays window 450 of Fig. 4(d). 

[0083] Fig. 4(d) shows a window 450 or similar navi- 
gational element for the privacy function of button 438. 
Window 450 allows a user of the diary to set a privacy 
level at which the diary is operating of: world, friend, 
close friend, best friend, and owner via respective but- 
tons 451 , 452, 453, 454, and 455 Any user can change 
the privacy level, provided that he is able to authenticate 
himself, e.g., via a password supplied in area 456*. This 
window determines which sections and which objects 
will be visible during browsing through the diary. If the 
user selects the owner privacy level (button 455) and 
can supply a correct password in area 456, after clicking 
OK button 457, buttons 440, 442, 444. and 446 of Fig. 
4(a) become available to the owner. Otherwise these 
buttons are grayed out. Use of button 440 will pop-up a 
new window containing the advanced diary operations 



such as. e.g., moving or copying objects from one sec- 
tion to another. The passwords for a particular user's 
diary pages are stored as configuration information in 
that user's diary information 114. 

5 

3. Adding a Note on a Diary Page 

[0084] Button 442 provides a way for the owner to 
make quick notes with an optional associated link in the . 

10 diary. Fig. 4(e) shows a window 460 or similar naviga- 
tional element for the note function of button 442. Win- 
dow 460 includes an area 461 in which a diary owner ^ 
can enter an address (such as a URL) of a link in the 
diary. The window also includes an area 462 where the 

15 diary owner can enter his text. After the diary owner en- 
ters a link address and some text, applet 1 1 2 adds the 
entered text to the diary information in association with 
the entered link on the page. When the diary page is 
viewed, the note (with the link attached to the note) will 

20 be displayed as part o! the diary page. 

4. Store function 

[0085] Store button 444 stores the AUA-database, the 
2S configuration, and the backup AUA-database if and only 
if these three parts of the diary information have been 
created (only in case of the backup AUA-database) or 
changed. Button 444 is enabled by diary applet 112 
when something in the diary has been changed. In the 
30 described embodiment, the diary also saves the diary 
information when the user instructs the browser to load 
a Web site different from the diary server. This will cause 
the browser to unload the diary, which automatically 
starts the save option. 

35 

5. Advanced functions 

[0086] Button 446 provides access to certain ad- 
vanced functionality as described below. Fig. 4(1) shows 

40 a window 470 or similar navigational element for the ad- 
vanced function of button 440. Window 470 includes 
four upper left-hand buttons 471 . 472, 474, 475, which 
allow the diary owner to modify his AUA-database. With 
these buttons an owner can add a content entry (button 

45 471 ), add a section (button 472), change passwords for 
privacy levels (button 473). put diary in edit mode (but- 
ton 474), edit section properties (button 475), and make/ 
load backup (button 476). Button 477 is a special button 
available only to content providers. 

50 [0087] Button 473 allows the owner to change pass- 
words for the four privacy levels that are shown in Fig. 
4(b). All users must enter an appropriate password be- 
fore diary applet 112 will generate HTML (for content 
objects) or otherwise reveal the existence of objects 

55 having those privacy levels (e.g., for named sections in 
the named section list 404). Button 476 allows the user 
to backup/load the diary contents. Button 477 is only 
present if the user v^o is running the diary applet Is also 
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registered as a content provider. Button 477 allows a 
content provider to change an existing "standalone" 
HTML file in such a way that It will, after the change, 
provide content for any user to include in their diary. If 
the diary owner adds a section to his diary via button 
472 (or changes a section via button 475), the diary own- 
er only needs to specify the name of the section (window 
not shown). Diary applet 112 will add a section to the 
user's diary having the specified section name using the 
default cover for the diary. 

i. adding content entries 

[0088] Fig. 4(g) shows a window or similar navigation- 
al element for the add content button 471 of Fig. 4(f). 
This window allows an owner to add his own content 
entries to his diary. The diary owner selects a type of: 
image 412, text 413, applet 414, or embedded object 
415. Depending on which type of content the diary own- 
er is adding, an appropriate window, such as the window 
in Fig. 4(h) is displayed. 

[0089] Fig. 4(h) shows a window 480 or similar navi- 
gational element to allow the diary owner to add his own 
image entries to his diary. This requires specifying the 
address (such as a URL) of the image (in area 487), as 
well as the real width and height of the Image in areas 
488 and 489. The buttons on the top row are used to 
specify whether or not to provide the image to other diary 
owners, i.e., whether other diary owners can copy the 
content from a diary into their own diary (button 481), to 
set a weight (button 482), to set a time button 484, to 
set a privacy level for the image (button 485), and to 
provide a textual description of the image in the diary 
(button 486). Image weights are used, for example, 
when a series of Images are available. Each image in 
the series is assigned a weight so that applet 112 can 
order the images if needed. Time button 484 associates 
a time (such as a creation date or a date in history) with 
the image. The date associate with an object is implicit, 
since the object is part of a dated section, but an object 
can have an associated time. Under certain circum- 
stances, applet 112 will generate a diary page having 
the Images of the page in time-sorted order Diary applet 
112 will add an image to the current section (that is, the 
entry just created). Although not shown in the figures, 
similar windows exist to allow the diary owner to add 
content of types text, applet, and embedded object to a 
diary page. An embedded object is the HTML term for 
an "external" object type, such as a Quick-Time movie, 
ReadAudio, RealVideo, etc. 

il. modifying content entries 

[0090] Button 474 of Fig. 4(f) causes applet 1 1 2 to dis- 
play an edit mode window 490 as shown in Fig. 4(i), 
which enables a diary owner to modify content entries 
that are already in the diary. As shown in Fig. 4(j), in this 
mode, entries 401 in a diary page are generated by diary 



applet 1 1 2 to have a clickable border 499 or some sim- 
ilar Indicator (which can be cover specific). Clicking this 
border 499 brings up the window 490 shown in Fig. 4(i). 
Window 490 offers an owner the ability to modify the 

5 position of the entry in the section: move to top position; 
move one position up; move one position down; move 
to bottom position (buttons 491 , 492, 493, and 494), and 
the ability to copy, move, or delete the selected entry 
(button 495). The diary owner can change properties of 

10 a content object on a diary page via button 496, which 
opens a window (not shown) similar to that which is used 
to add an entry (see Fig. 4(h)), with at least one differ- 
ence. 

[0091] Content entries that are provided by third par- 
is ties are not modifiable. Because a content provided has 
invested time, money, and/or energy in the creation of 
a diary object, and because content providers should be 
encouraged to continue to supply content, users are not 
allowed to change any aspect of an object that was pro- 
20 vided by a third party. This will prevent undesirable user 
actions such as changing the link associated with an im- 
age of Company A (that originally pointed to some spot 
in the web site of Company A) to point to some spot in 
the web site of company A's biggest competitor. Only the 
2S time, privacy level, and description can be changed by 
the diary owner. Note that the time, privacy level, and 
description were the entries added by the diary owner 
himself (as opposed to transferred from a content pro- 
vider web page) 
30 [0092] Fig. 4(1) is a flowchart showing steps involved 
in editing an existing content object. The above opera- 
tions are implemented through control by means of dy- 
namic HTML generation. A flowchart is given below in 
figure 11 . By setting the WSDiary in edit mode, the HTML 
35 generator re-generates the page and adds object con- 
trol handles (in this case of type "edit") to the page. The 
user clicks on a control handle. The handle identification 
is passed on to the HTML generation engine (by Java- 
Script in the current embodiment). Any appropriate ac- 
40 tion is executed on the object identified by the handle 
and represented in HTML. Finally, a new (updated) page 
is generated and displayed. In step 250, once diary ap- 
plet 112 determines that the page is in edit mode, applet 
112 regenerates the page to add an object control "han- 
45 die" 499 to each content object on the diary page (see 
Fig. 4(j)). In step 251 , when the diary owner clicks on a 
control handle, the browser initiates executable pro- 
gram code (e.g., Java or JavaScript) that has been gen- 
erated by applet 112 and added to the HTML edit-mode 
so page being displayed. When the diary owner clicks on 
the handle 499, the browser executes this program code 
in a manner known to persons of ordinary skill in the art. 
The program codo then communicates with applet 112 
to tell it which content object has been selected for ma- 
ss nipulation. Applet 112 then displays appropriate win- 
dows (see. for example, Figs. 4((f) and 4(k)) to allow the 
diary owner to manipulate the selected content object). 
Diary applet 112 executes appropriate action(s) on the 
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selected content object identified by the handle 499. In 
step 253. diary applet 112 regenerates the HTML for the 
diary page to reflect the edit, after which the HTML is 
displayed by browser 110. 

[0093] The reason that diary applet 112 must gener- 
ate an executable program associated with each handle 
is that there is no other way for applet 1 1 2 to learn when 
the diary owner has clicked on a handle 499. The HTML 
for a diary page is actually displayed by browser 110, 
and the browser would not otherwise notify applet 112 
of a handle click. The method of Fig. 4(1 ) enables em- 
bodiments such as a diary to display and manipulate 
contents within an HTML document and, at the same 
time, uses the browser as a vehicle to handle the actual 
display an diary owner input. Using the browser avoids 
having to duplicate the browser functions that interface 
to the user and that display pages in accordance with 
HTML. 

[0094] Thus, for example, in Fig. 4(j), diary applet 1 1 2 
has already regenerated the diary page to display a han- 
dle 499 around the object and to add an executable pro- 
gram in the HTML for the diary page. This executable 
program is associated with the handle and will be exe- 
cuted when the handle is clicked. In the described em- 
bodiment, when the handle 499 is clicked, the associat- 
ed executable program will pass the identity of the se- 
lected content object to applet 112, which will then dis- 
play the window of Fig. 4(i). This window (and the other 
windows described herein) are generated by applet 112 
and are not displayed via the browser If the diary owner 
indicates via several presses of button 494 of Fig. 4(i) 
that the content object is to move to the bottom position, 
applet 112 will eventually regenerate the diary page to 
look like the diary page in Fig. 4(m). Note that the se- 
lected content object has been moved to the bottom 
right on this diary page (which the cover for this diary 
has defined as the bottom position of this diary page). 
Applet 112 communicates with the browser to display 
the regenerated HTML of the diary page. Once the diary 
owner clicks on accept button 406 of Fig. 4(i), applet 112 
is caused to exit edit mode (via another executable pro- 
gram) and regenerates the diary page without handle 
499 to yield a page such as the page of Fig. 4(n), where 
content object 401 is again displayed in its new position, 
but without a handle. The next time this page is saved 
to diary server 104, this positional change is saved in 
the user's diary information 122. 

[0095] If the owner has entered edit mode and then 
presses button 495 of Fig. 4(f), applet 112 generates 
HTML for the window of Fig. 4(k), which allows the diary 
owner to perform various copy and move operations on 
a content object in a diary page. As another example, if 
the diary owner clicks handle 499 of Fig. 4(j), executable 
code In the regenerated page associated with the se- 
lected handle 499 executes to alert applet 112. If the 
user now clicks button 495, applet 1 1 2 displays the win- 
dow of Fig. 4(i), which Includes a copy button 350. a 
move button 360, and a delete button 361. 



[0096] The destination section for a content cdDject 
while copying or moving might already contain an iden- 
tical content object. If the owner desires to have another 
content object in the destination section (i.e.. one more 

5 than before the operation), he checks the "allow dupli- 
cates' box. If he does not check this box, and if an iden- 
tical content object already exists at the destination, the 
content object will not be put in the destination section. 
[0097] If the diary owner indicates that he wants to 

10 copy the content object (by pressing button 350 of Fig. " 
4(k)), diary applet 1 1 2 will allow the diary owner to spec- 
ify a dated or an undated page In a manner similar to 
that of Figs. 4(b) or 4(c). Diary applet 112 then regener- * 
ates HTML for the page to which the object is to be cop- 

15 led. When the diary owner exits edit mode, a page such 
as that of Fig. 4(o) will be displayed. Note, that In the 
example, the selected content object has been copied 
to a page having a different date than its original page. 
The next time this page is saved to diary server 1 04, this 

20 change is saved in the user's diary information 122. 
Note that in both examples above, an end-user has 
been able to modify a page display able in a browser (e. 
g.. a diary page) without writing any HTML code. 

25 D. Transferring Data from a User's Diary to the Diary 
Server. 

[0098] It should be understood that, although the fol- 
lowing example Is described in terms of a transfer func- 

30 tion for a diary, the transfer function described can be 
used In any circumstances where a first machine (such 
as system 106) sends data (e.g.. third party content) to 
a second machine (such as system 102), and the data 
then needs to be send to a third machine (such as sys- 

35 tem 104) under control of an applet executing in a 
browser on the second system. The present Invention 
Is contemplated to be of use in non -diary applications, 
as well as in diary applications. 

[0099] Fig. 5(a) shows an overview of a first embodi- 

40 rnent of a data transfer function involving three ma- 
chines. Fig. 5(b) shows an overview of a second em- 
bodiment of a data transfer function, Involving three ma- 
chines. Fig. 5(a) will be discussed first. In step 1 of Fig. 
5(a), the browser 1 1 0 loads the content provider's HTML 

45 page from system 106 into browser 1 10 in system 102. 
This HTML page includes a function "F" 502 that can be 
activated by the user via the HTML page (for example, 
clicking on a 'add" button on the page). The user tooks 
at the content provider's page (as displayed by the 

50 browser) and determines whether there is any third par- 
ty content on the page available for his diary that he 
wants to add to his diary. If so, the user so Indicates. For 
example, in the described embodiment, the user clicks 
on an "add" button 602 on the HTML page (see Fig. 6 

55 (a)) associated with the desired third-party content. 
Clicking on this content activates function "F" 502 within 
the displayed Web page, as shown In step 2 of Fig. 5 
(a). In the described embodiment, function "F" is a Java- 
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Script, but it can be any appropriate form of executable 
program. 

[01 00] As shown in step 2 of Fig. 5(a). the function "F" 
pops up a window 504 thai asks the user for his name 
and for the location of the diary provider 104 (step 3). 
Function "F" needs the name/exact location of diary pro- 
vider 104 so that it can generate HTML page 506 (step 
4) that requests the transfer applet 508 from the correct 
diary server 104. (Note that certain embodiments can 
have more than one diary server 104). An example of 
window 504 displayed by function "F" is shown in Fig. 6 
(b). 

[0101] In step 4, the function "F" also generates HTML 
506 that contains: 

1) activation of a transfer applet (to be loaded from 
the diary server 104) (step 5 and 6), and 

2) the parameters of the transfer applet containing 
all information about the provided content. 

[0102] Thus, function "F" knows how to generate the 
HTML to activate transfer applet 508 (at the host stored 
by the user) with the parameters of the information to 
store 

[0103] In step 5, function "F' instructs browser 110 to 
load the HTML page 506 in a new HTML-browser win- 
dow. By loading that page 506, the browser will load and 
execute the transfer applet 508 on system 102 (step 6). 
When transfer applet 508 executes, it transfers data to 
system 104. The function "F" uses a priori knowledge 
about the name/exact location of the transfer applet on 
diary server 104. Similarly, function "F" uses a priori 
knowledge about the names and semantics of the pa- 
rameters required by the transfer applet. 
[0104] It Is important to note that, due to a security 
restrictions common to many implementations of exe- 
cution environments of programs such as Java applets, 
transferring data between three machines (102, 104, 
1 06) is problematic. Because the data eventually has to 
be stored on system 104, because communication may 
have been to be set up with the diary applet already run- 
ning on the system 102, and because the diary applet 
was loaded from system 104, the transfer applet 508 
also must be loaded from system 104. The problem Is 
how to get the information describing the content pro- 
vided to the transfer applet 508 if the transfer applet is 
to be loaded from server 104. For instance, the transfer 
applet is not allowed to connect to the content provider 
system 106. The problem is solved by generating the 
HTML page 506, which contains the instructions that ac- 
tivate the transfer applet 508 in combination with all in- 
formation about the content provided that should be 
handled by the transfer applet. In other words, the HTML 
page 506 is self-contained and the transfer applet acti- 
vated by it can handle the transfer without any other 
communication other than with its source system 104, 
which is allowed since it was loaded from system 104, 



Thus, the method shown in Fig. 5(a) solves the problem 
caused by the security restraints of the execution envi- 
ronment. 

[0105] In at least one embodiment, the database is 

5 not really transferred immediately, but is only scheduled 
for storage. A running diary applet performs the actual 
storage. If there is no running diary applet in browser 
1 1 0, the transfer applet will start one. Similarly, in at least 
one embodiment, all applets store to a "store queue." 

10 This way. the transfer applet 508 can insert a database 
in the queue that will be processed by another diary ap- 
plet 112. Sharing of the new content (as transferred by 
the transfer applet) with the diary applet is extremely im- 
portant because the new content will have to be made 

15 visible by the diary applet immediately and efficiently, e. 
g., it would not be acceptable to if it would require a user 
action in order to view the new content. Similarly, it 
would not be acceptable if it would require a full "re-up- 
load" of the diary information 114 by the diary applet in 

20 order to view the new content. The underlying funda- 
mental mechanism on which the sharing has been 
based is the sharing of class variables in a single Java 
virtual machine. 

[0106] Table 1 shows an example of a JavaScript that 
2S performs the function of function "F" of Fig. 5(b). Table 
1 , which is an HTML/Javascript, forms a part of the spec- 
ification and is incorporated herein only for purposes of 
example. 

[0107] Fig. 5(b) shows an alternate embodiment of a 

30 transfer function in which the function "F" does not have 
a priori knowledge about the name/exact location of the 
transfer applet 508. It can be advantageous to have 
function "F" not know the name/exact location of the 
transfer applet. Because there are many function "F's 

35 in the network - each content provider 106 has HTML 
containing a version of function "F" - it can be problem- 
atic if the diary server 104 decides to change the name 
of the transfer applet 508. If each functran "F" (which 
resides on the content provider(s) 106) knows the name 

40 of the transfer applet 508, each function "F" would have 
to be changed if the name/location of the transfer applet 
508 is changed. If the function "F" does not know this 
information, function "F" does not have to change if the 
name of the transfer applet 508 stored on system 1 04 

45 changes. 

[01 08] In Fig. 5(b), function "F' (received from system 
106) pops up window 504 as described above and cre- 
ates a "network package" 507 that contains at least; 

so - the name of the server 104; 

the name of the user; and 

the properties of the content to be transferred. 

55 

Network package 507 is POSTed to diary server 104. 
Diary server 104 generates the page 506 using the in- 
formation in the network package 507 and returns it to 



so 
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function "F' in system 102. Function 'F" continues as in 
fig. 5(a). Specifically, function "F" instructs browser 110 
to load the HTML page 506 in a new HTML-browser win- 
dow. From this point onwards, the embodiment of Fig. 
5(b) behaves as the embodiment o1 Fig. 5(a). 
[0109] It will be appreciated that in this embodiment, 
the a priori knowledge of function "F" is limited to only 
the way the network package 507 is to be structured, 
the content that is to be put into network package 507, 
and the way this package 507 is to be sent to diary serv- 
er 104. The amount of knowledge required is less than 
the knowledge required to generate page 506 itself. 
[0110] It will be appreciated that the embodiment of 
Fig. 5(b) limits the "outer world" restrictions on the Inter- 
face of diary server 104. Once the diary server 104 is in 
operation (as illustrated In Fig. 5(b)), it should always 
support the handling of network packages 507. Howev- 
er, the internals of page 506 may be changed by the 
diary server 104 whenever such a change is required. 
Note that such a change is not an option in the embod- 
iment of Fig. 5(a), since the a priori knowledge about the 
contents of page 506 have been spread over numerous 
content provider systems 106. 

[01 11 ] Figs. 7(a) and 7(b) show examples of windows 
displayed by transfer applet 508 during transfer of data 
between three machines. As described above, once 
page 506 is loaded, the transfer applet 508 will be acti- 
vated automatically and it will pop-up the window shown 
in Fig. 7{b). This window shows a list 701 that represents 
the objects being transferred. In the Figure, there is only 
one object to be transferred. Each entry is represented 
t}y a textual line that consists of the suggested destina- 
tion (or the destination suggested by the user, see be- 
low) for the entry (in this case, the section May 28, 
1998), followed by a textual description of the entry 
(which in this case is "nice car"). 
[Oil 2] Each of the entries in the current transfer may 
be deleted from the list 701 by selecting the entry in the 
list 701 and then clicking delete button 703. The desti- 
nation section of each entry in the current transfer may 
be changed by selecting the entry in the list and then 
clicking the button 702. The transfer applet 508 will pop- 
up a window similar to that of Fig. 7(a). Fig. 7(a) is sim- 
plified in that the user will be able to select any date for 
the destination section or any of the named sections that 
exist in the diary. The role of the check 704 is exactly 
like the role of check 406 described atx)ve. 
[0113] After the user has deleted the entries that he 
is not interested In, and after he has changed the des- 
tinations of entries to entries that he considered appro- 
priate, he presses either the OK button 406 (Fig. 4(a)) 
or the cancel button 405. If the cancel button is pressed, 
the whole transfer is cancelled. If the OK button is 
pressed, the transfer applet 508 will add the entries to 
the AU A-database in the user diary data 1 22 on the user 
system 102. In one embodiment, transfer applet 508 is- 
sues a "store" command that is queued in the store 
queue and checks whether a diary applet is already run- 



ning. If no diary applet is running, the transfer applet will 
start a diary applet automatically. 

E. System Architecture 

5 

[0114] Fig. 8 shows an exemplary architecture for an 
emtx)diment of the present invention. As shown by the 
key. the architectural diagram includes a top layer rep- 
resenting two types of users: cover providers 802 and 

10 users 804 (diary owners and other users). A sectbn 806 
represents the functionality of diary applet 112. A sec- 
tion 820 represents browser 110. A section 822 repre- . 
sents the Internet (or other appropriate network or way 
of communicating between entities). A section 830 rep- 

15 resents diary software, such as diary software 124 of 
diary server 104. 

[Oil S] In the described embodiment, cover providers 
and end-users both run diary applet 112. However, cov- 
er providers have access to special functionality for con- 

20 structing covers that end users do not have. It should 
be noted that diary applet 112 runs "inside" browser 110. 
It communicates with the user through the browser win- 
dow and through its own user interface 807. The diary 
navigator 807 provides standard navigation functionality 

2S to the user (via navigation bar 400). It also acts as an 
intermediary between the browser and the rest of the 
diary applet 112. One of Its important tasks is to transfer 
the pages of the diary to browser 110. Diary pages are 
generated by a generator in the diary applet. This gen- 

30 eration is performed by combining data from covers (al- 
so called "presentation contexts") designed by a cover 
provider and the content that the user has gathered for 
his diary. 

[0116] Because of privacy concerns, content is "fll- 
35 tered" by the session layer, which allows the user to see 
only the content that he is permitted to see. The user's 
content is stored in the AU A-database. User settings are 
stored as configuration data, which includes the pass- 
words required for users to access the different privacy 
40 levels. The user also has the possibility to create back- 
ups of the AUA-database. 

[0117] The network layer takes care of transferring all 
diary files over the internet (or other network) between 
the user and the content provider. In the described em- 

45 bodimenX, all network traffic is routed through the brows- 
er 110. This is necessary to be compatible with proxy 
and firewall setups In corporate networks. All files pref- 
erably are stored in a diary server, such as diary server 
104. They can be accessed from anywhere on the net- 

50 work. 

F. Data Structures 

[0118] Fig. 9 lists exemplary files provided by cover 
ss providers in a preferred embodiment of the present in- 
vention. Fig. 10 lists exemplary tiles provided to gener- 
ate the contents of diary pages in a preferred embodi- 
ment of the present invention. As shown in Figs. 8 and 
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9, these files include cover-specific files, such as: diary 
specific HTML files, images, HTML-covers, and a gen- 
erator configuration file. As shown in Figs. 8 and 10. 
these files further include user-specific files, such as: 
diary information, a user config file 838, and backup in- 
formation 840. 

[0119] Fig. 11 shows an exemplary format of an AUA- 
database of Fig. 10. The Diary's content database con- 
tains the content a user has gathered. This content 
comes in many types, but since it should be viewable in 
an HTML-browser, the distinction between content 
types used by HTML will be adopted. HTML supports 
these four types of content: plain text, images, applets, 
embedded objects. Each content entry is shown on one 
specific Diary section, so the database stores the con- 
tent on a per-section basis. As there are two kinds of 
sections (date sections and named sections), this struc- 
ture is a little more refined. Figure 11 shows the structure 
of the content database. As discussed above, the de- 
scribed embodiment supports the following types of 
content: plain text, images, applets, and embedded ob- 
jects. The AUA-database is broken into two types of sec- 
tions: dated sections (see, for example. Fig. 4(o)) and 
named sections (see, for example, Fig 4(a)). In the ex- 
ample, the dated sections include a number of date sec- 
tions 1106. The named sections include a number of 
named sections 1110. Each date section 1106 is broken 
into a plurality of dated content entries 1108. Each 
named sections 1110 is broken into a number of content 
entries 1112 In the described embodiment, the entire 
structure 114 Is stored as a ASCII document. Because 
bandwidth and storage capacity are scarce resources 
in the diary applet 112, certain embodiments compress 
larger Java objects when they are stored. 
[0120] Fig. 12 shows exemplary cover HTML-files. 
Covers are also called "presentation context." In one 
embodiment of the present invention, the presentation 
context can consist of HTML files in which "on the fly" 
substitutions by the diary applet are performed. Fig. 12 
shows the rules to apply to such HTML-files. As an ex- 
ample, the occurrence of a "wifentry.g if "object in a cover 
represents a box in which the diary applet may place the 
representation of a content object. As another example, 
a list of textual strings such as _YEAR_ will be substi- 
tuted by the diary applet by the year (e.g. , "1 998") of the 
date section that is to be shown. 
[0121] To specify the layout of the generated HTML- 
pages, the Generator uses HTML-templates. Each 
HTML-templates uses the following Diary conventions 
that allow on-the-fly tailoring of the files: 

1. Each image in the HTML-template named wifen- 
try.gif is a placeholder for an entry: in W3Diary 
terms, each wifentry.gif represents a box. 

1 . The dimensions of the wifentry.gif in the orig- 
inal HTML-template will determine the bound- 
ing box of an entry. 



2. The cover designer can indicate that the 
bounding box may be rotated by 90 degrees if 
that improves the fit. 

5 2. Boxes must be inside an HTML table in order to 

allow correct generation of content surrounded by 
edit or provide images. 

3. For pages in 'date' sections, each box should be 
accompanied by a time generator tag so that time 

10 information attached to a content entry can be vis- 
ualized. 

1. While viewing the template, each time gen- 
erator tag should be close to its box. 

15 2. In the HTML-file, the order of the list of the 

_TIME_generator tags should be the same as 
the order of the list of the corresponding wifen- 
try-gif's. Note: this results in HTML table de- 
signs in which the time generator tags are 

20 above (or below) each corresponding box. You 

cannof alternate the place (above/below) of the 
time generator tag with respect to its corre- 
sponding box. For, by doing that, the sequence 
of the time generator tags is not the same as 

2S the sequence of the boxes. 

4. Optionally, include at any spot and in any context 
one or more of the following generator tags. 

30 [0122] Fig. 13 shows a diagram of a relationship be- 
tween various kinds of covers and the layout of pages 
generated by a diary applet in an embodiment of the 
present invention. The individual cover template HTML 
files are bound (like pages in a book). The "priority se- 

35 quence" of these HTML-templates plus any other (meta) 
information about those HTML templates is stored in a 
file. This file is called "w3diary.wif (WIF stands for 
W3diary Intermediate Format"). The Generator uses the 
WIF file to match templates to a w3diary section. The 

40 WIF object is used to configure the generator. The Gen- 
erator includes multiple ordered sets of Templates 
(which have their own variables) and of global variables. 
So the WIF object is just an efficient representation of 
the Generator. 

45 [0123] The WIF object is used to configure the Gen- 
erator The Generator consists of multiple ordered sets 
of Templates (which have their own variables) and of 
global variables. So the WIF object is just an efficient 
representation of the Generator 

50 [0124] In summary, the described embodiment of the 
present invention allows users to create "diaries" that 
can be read via a web browser. The owner of a diary 
can read his own diary and certain non -private parts of 
the diary can be read by other persons. Thus, the owner 

ss of the diary can control what is presented to various 
classes of persons via his diary. The owner can identify 
various pages, sections, or content objects as having a 
certain privacy level. When a diary applet executing in 
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the browser receives information for the user's diary: the 
diary applet generates HTML only for those portions of 
the diary that have a privacy level lower than or equal 
to the privacy level of the viewer who is viewing the diary. 
Thus, it is possible that the diary applet will generate s 
different HTML pages for an owner and for a random 
stranger who each ask to view the same diary page on 
their respective browsers. The person viewing a diary 
page can only view that content marked as appropriate 
for him and other people at his privacy level. The diary io 
applet of the described embodiment asks for a pass- 
word to determine a privacy level of a person. The cor- 
rect password values are part of the configuration Infor- 
mation for a diary. 

[0125] A user can navigate amongst diary pages like 
pages In a book. A user can add various types of content 
to his diary page and can also add content provided by 
content providers via their web sites. The diary owner 
can also move content around on a diary page and can 
copy or move content from one page or section to an- 20 
other page or section. The diary owner can also transfer 
content from the diaries of others, assuming that the 
original creator of the content object allows transfer of 
the ob'\ecX. The original creator might have been the di- 
ary owner, another diar/ owner, or a content provider. 2S 
[0126] The invention uses a transfer method that 
avoids certain security restrictions that are problematic 
when downloading third party content to a diary. While 
the Invention has been described In conjunction with a 
specific embodiment, It is evident that many alterna- 30 
fives, modifications and variations will be apparent to 
those skilled in the art in light of the foregoing descrip- 
tion. For example, diary applet 11 2 could, instead be im- 
plemented as a plug-in to browser 1 1 0. This has the ad- 
vantage of being free of the Java "sandbox," but re- 3S 
quires a different plug-in for each type of browser and 
needs to be installed by the user before it can be used. 
The functionality of the diary applet 112 could also be 
Implemented In the browser. Moreover, some or all of 
the of the processing and selection of content could be "to 
performed on the diary server 104, thus saving the 
amount of data that must be transferred to the browser. 
Similarly, all of the HTML generation could be performed 
by the diary server 104. This might lower the bandwidth 
required and would simplify the transfer mechanism. 4S 
However, when envisioned in an application of the in- 
vention where millions of users use a diary, this places 
an unacceptable burden on the diary server(s) 104. In 
the described embodiment, the processing capabilities 
of the user systems 1 02 are used to avoid this problem, so 
Accordingly, it is intended to embrace all such alterna- 
tives, modifications and variations as fall within the 
scope of the invention. 

[01 27] As indicated above, emtxxjiments of the inven- 
tion are not limited to any specific combination of hard- S5 
ware and software. Where an embodiment includes 
software components, these can form a computer pro- 
gram product. Program Instructions could be provided 



on any suitable carrier medium, for example a computer 
readable medium such as a storage medium (e.g. solid 
state mennory, optical and/or magnetic media, etc.) and/ 
or a transmission medium (e.g. a carrier wave, tele- 
phone tine, wireless link. etc.). 



Claims 

1. A method of editing content displayed on a diary 
page described by a web descriptor language, com- 
prising: 

receiving an indication from the user to enter 
an edit mode for the diary page; 
generating In response to the indication, by a 
executable diary program running within a 
browser, a second executable as a part of the 
descriptor Ian guage of the page, where thesec- 
ond executable informs the executable diary 
program whenever the user selects content to 
edit; 

displaying a user edit interface, by the execut- 
able diary program after being informed by the 
second executable that the user has selected 
content to edit; and 

regenerating descriptor language, by the exe- 
cutable diary program, running within the 
browser, for the diary page in accordance with 
edits made via the user edit Interface. 

2- The method of claim 1 , where the second executa- 
ble is associated with a handle displayed around the 
content during edit mode. 

3. The method of claim 2, wherein the handle Is not 
displayed on the regenerated page that Incorpo- 
rates the user's edits. 

4. The method of any preceding claim, wherein the de- 
scriptor language Is HTML. 

5. The method of any preceding claim, wherein the ex- 
ecutable diary program allows only the owner of a 
diary page to enter edit mode tor that diary page. 

6. The method of any preceding claim, wherein the us- 
er edit interface allows the user to modify the posi- 
tion of content on the diary page. 

7. The method of any preceding claim, wherein the us- 
er edit interface allows the user to copy content on 
the diary page. 

8. The method of any preceding claim, wherein the us- 
er edit interface allows the user to move content on 
the diary page. 
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9. The method of any preceding claim, wherein the us- 
er edit interface allows the user to delete content on 
the diary page. 

10. The method of any preceding claim, wherein the us- 
er edit interface allows the user to change the prop- 
erties of content on the diary page. 

1 1 . The method of any preceding claim, wherein the ex- 
ecutable diary program receives a handle identifi- 
cation from the second executable. 

1 2. An apparatus that allows a user to edit content dis- 
played on a diary page described by a web descrip- 
tor language, comprising: 

a software portion configured to receive an in- 
dication from a user to enter an edit mode for 
the diary page; 

a software portion configured to generate in re- 
sponse to the indication: by a executable diary 
program running within a browser, a second ex- 
ecutable as a part of the descriptor language of 
the page, where the second executable informs 
the executable diary program whenever the us- 
er selects content to edit; 
a software portion configured to displaying a 
user edit interface, by the executable diary pro- 
gram after being informed by the second exe- 
cutable that the user has selected content to 
edit; and 

a software portion configured to regenerate de- 
scriptor language, by the executable diary pro- 
gram, running within the browser for the diary 
page in accordance with edits made via the us- 
er edit interface. 

13. The apparatus of claim 12 where the second exe- 
cutable is associated with a handle displayed 
around the content during edit mode. 

14. The apparatus of claim 1 2 or claim 1 3, wherein the 
descriptor language is HTML. 

15. The apparatus of any one of claims 1 2 to 14, where- 
in the executable diary program allows only the 
owner of a diary page to enter edit mode for that 
diary page. 



in the user edit interface allows the user to move 
content on the diary page. 

19. The apparatus of any one of claims 12 to 18. where- 
5 in the user edit interface allows the user to delete 

content on the diary page. 

20. A computer program product for causing a compu- 
ter to effect: 

10 

receiving, by an executable program that is as- 
sociated with the descriptor language for the 
web page, an Indication that a user want to edit 
the page content that is being displayed by the 

IS web browser; 

generating a visible indicator associated with 
the content displayed by the browser that edit 
mode has been entered, the Indicator having 
an associated second executable program; 

20 displaying a user edit interface, by the execut- 

able program after being informed by the sec- 
ond executable program that the user wishes 
to edit the page content; and 
regenerating descriptor language, by the exe- 

25 cutable program, running within the browser, 

for the web page in accordance with edits made 
via the user edit interface. 

21. The computer program product of claim 20, com- 
30 prising program instructions on a carrier medium. 

22. The computer program product of claim 21 , wherein 
the carrier medium is a computer-readable medi- 
um. 

35 

23. The computer program product of claim 21 or claim 
22. wherein the carrier medium is a storage medi- 
um. 

40 24. The computer program product of claim 21 or claim 
22, wherein the carrier medium is a transmission 
medium. 



45 



1 6. The apparatus of any one of claims 1 2 to 1 5, where- so 
in the user edit interface allows the user to modify 

the position of content on the diary page. 

17. Theapparatusof anyoneof claims 12to 16, where- 
in the user edit interface allows the user to copy con- 55 
tent on the diary page. 

18. Theapparatusof any oneof claims 12 to 17, where- 
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Figure 4(c) 
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Figure 4(d) 
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Figure 4(f) 
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Figure 4(j) 
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Inside a browser 
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Put in: 
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Cover-specific files; 

These files are provided by cover designers. 

• Diary specific HTML-files. 

These files are shown in the browser at times the Diary is in some non- 
interactive state (e.g. while the Diary Is starting up). 

• Images. 

A cover designer can provide images for the Diary user interface. For 
example, cover-specific graphics for the buttons in the user interface 
may be provided. 

• HTML templates. 

These files specify the layout of the Diary pages. 

• Generator configuration file. 

This file contains information for the generator about the mapping of 
templates to Diary pages. It is created using "Instant Cover", Diary's 
integrated cover design tool. 



Figure 9 



User-specific files: 

These files contain each W3Diary's user specific data: 

• AUA-Database. 

The content database contains the contents of a user's Diary. 

• Config. 

This file contains the user settings (see Config. above). 
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Generator Tag 


Substituted By 


Example Value 


.SECTION. 


the name of the section 


Addresses 


.OATESTRiNG. 


the date 


March 13, 1998 


-YEAR. 


the year 


1998 


.MONTH. 


the month 


3 


.MONTHNAME. 


the month 


March 


-DAY. 


the day of the month 


13 


.WEEKDAY. 


the day of the week 


Friday 


_TIMEt2. 


the time of an entry in am/pm 


9:30 pm 


_TIME24. 


the time of an entry, 24 hour based 


21:30 


-PAGE. 


the number of the current page within a section 


2 


.MAXPAGE. 


the total number of pages in a section 


5 



Figure 12 
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